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BP ctitecatin of microprocessor based products neces- 
sitated the design of microcomputer development systems. 
These tools represent either general purpose or univer- 
sal investigative aids that support several micropro- 
cessor types, or dedicated aids restricted specifically to a 
single microprocessor type or family. A system assisis 
the designer in evaluating alternative microcomputer 
hardware or software prototypes because it incorporates 
all standard computer development tools, such as the 
central processor, mass storage memory, control con- 
sole, editor, assembler, and compiler. Also, simultaneously 
testing hardware and software produces powerful de- 
bugging capabilities (Fig 1). 

Specialized in-circuit emulator types of microcomputer 
development systems evolved to handle problems in- 
herent in separating hardware and software defects. 
These include the Futuredata Microemulator and Tek- 
tronix In-Prototype Emulator that support micropro- 
cessots from a variety of manufacturers, the Intel IcE 
and Motorola UsE that support a family of micropryo- 
cessors, and single-microprocessor systems from RCA, 
Rockwell, and Zilog. The in-circuit emulator provides 
the most accurate method for testing and checking mi- 
crocomputer system hardware and software. It replaces 
the central processing unit (cpu) chip in the system 
under test, duplicates the chip functionally, and fur- 
nishes indications of system operation and control at a 


console or terminal. The ability to examine, change, or 
modify CPU registers, storage memory, and program 
execution permits rapid and easy hardware and soft- 
ware testing. 


Hardware Elements 


A microcomputer development system consists of a series 
of hardware and software elements. Major hardware 
elements are the central processor, memory, mass sior- 
age, and control console (Fig 2). The central processor 
executes the various algorithms involved in the develop- 
ment task and, at times, executes an editor, an assembler, 
a debugger, and the designer’s program. Thus, it per- 
forms two major functions: hosi and designer program 
execution. 

Memory stores both program and data. These pro- 
grams can be host programs, such as the editor or com- 
piler, or designer programs. Data involve editor work- 
space, assembler symbol table, input and output (1/0) 
buffers, and/or data generated by the designer’s program. 

Mass storage stores operating programs, designer’s 
programs, and either temporary or permanent data. It 
is sometimes used as an extension of main memory. For 
example, when editing a large program, the editor work- 
space may not be large enough to contain the entire 
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program during edit. Moving the source program from 
one file in mass storage through the edit buffer to 
another file in mass storage accomplishes an edit. In 
this case, the two files and the editor work area com- 
prise a very large memory space. 

The control console provides an interface between the 
designer and the microcomputer development system. 
Systems differ greatly in the type of console used. Two 
primary functions of the console are to accept operator 
input (source programs, debugging commands, operat- 
ing system commands, data) and to provide feedback 
and output to the operator (assembly listings, memory 
dumps, register displays). 
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Essentially, these four hardware elements also con- 
stitute a software development system, of which the 
Intellec 8 and Intellec 80 are examples. The next 
three hardware elements, however, relate to the hard- 
ware development aspect of microcomputer design and 
apply specifically to microcomputer development systems. 

An in-circuit emulator provides a direct connection 
between the microcomputer development system and the 
prototype system. Read/write memory within the micro- 
computer development system simulates read-only mem- 
ory (ROM) or programmable read-only memory (P/ROM) 
in the prototype system. This greatly reduces the time 
needed to change and correct designer programs. Some 
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Fig 2 Relationship of universal development system hardware components. Components common to differing micro- 
processors include all |/O and memory devices. Only target central processor and in-circuit emulator interface are 


changed to accommodate specific microprocessor 


in-circuit emulators allow the designer to gradually switch 
functions into the prototype system. Thus, the designer 
separately tests the clock circuits, input control lines, 
and direct memory access (DMA) control system to 
evolve the final design in discrete increments. 

Final software can be stored in P/ROM using the 
P/ROM programmer. Programs debugged and running in 
simulator ROM are permanently burned into an elec- 
trically programmable ROM (EPROM) or P/ROM. 

Hardware debug aids, used in the debugging process, 
separate hardware and software problems. These aids in- 
clude a single-stepping facility, a hardware breakpoint 
facility, and a logic analyzer. With a single-step facility, 
the designer steps through the program one instruction 
at a time. A hardware breakpoint facility sets up a 
logical condition, usually an address, that halts the 
program whenever it encounters that address. Then, 
the designer can examine interim results, determine 
whether they are correct, and either continue executing 
the program or go back and modify it. In addition to 
providing hardware breakpoints, a logic analyzer cap- 
tures data on the fly and displays it. Thus, the designer 
views the system’s operation as a series of bus trans- 
actions. The logic analyzer has a fixed amount of storage 
that is continually updated by the last bus cycle, while 
the earliest bus cycle is erased. Therefore, when a hard- 
ware breakpoint is encountered, the logic analyzer mem- 
ory shows events leading up to the breakpoint. 


The microcomputer development system contains other 
1/o hardware elements. The printer provides hardcopy 
listings of the program, while other 1/o devices, such 
as a paper tape reader, a punch, or a modem, provide 
a standardized interface into other systems for data 
interchange. Thus, with a paper tape reader and punch, 
a designer may write a program ow,one development 
system and communicate it to another+development sys- 
tem. Likewise, with a modem, a designer connects a mi- 
crocomputer development system by telephone lines to a 
large computer which may have other processing facil- 
ities available (cross-compilers, cross-agsemblers, etc). 
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Software Elements 


Integrated into a development system are an editor, as- 
sembler, debugger, high level language compilers, link- 
age editors, and operating system—all software compo- 
nents. The editor creates and modifies source programs, 
written in assembly language or in higher level languages, 
depending on the task. The editor must, of course, have 
editing commands to change, delete, and insert lines of 
code; positioning commands to target on a particular 
location in the program where changes are to be made; 
and utility commands to read and write edited data. 
Editors differ in their capabilities and in their inter- 
actions with the control console. Most are written for 
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teletypewriter compatibility. To meet this design criterion, 
editors are designed with a small amount of information 
feedback. More recent designs use ultra high speed 
cathode-ray tube (crT) displays to provide context 
based editing and to offer a large amount of informa- 
tion feedback. A context based editor is very similar 
to the editors used in CRT word processor systems; here, 
a significant amount of the program is always “on dis- 
play.” A cursor within the display or context performs 
the editing; all changes instantaneously update the pro- 
gram as displayed. This feedback within the program 
context substantially reduces errors and simplifies edit- 
ing commands. 

The assembler translates or assembles the source code 
(assembly language), generated using the editor, into 
object code. Assemblers differ in their ability to handle 
macros, to generate relocatable code, to support a va- 
riety of operand formats, and to allow certain types of 
pseudo-instructions. The designer uses macros to name 
commonly used sequences of instructions, which then are 
“called” with a single instruction—the macro name. 

A debugger interactively executes and debugs the ob- 
ject program that is generated using the assembler or 
compiler. Commands handle memory display, program 
execution, and data storage in memory. With other com- 
mands, the designer sets breakpoints so that the pro- 
gram will halt when it encounters these breakpoints. 
Thus, the designer can determine the action of parts of 
the program. Additional commands set values in the 
processor registers, find data in memory, and read and 
write object program files. With the advent of in-circuit 
emulator capability, additional debugger commands map 
memory between the host and prototype systems, and 


switch the various microcomputer control lines between 
the host and prototype systems, thereby establishing the 
level of emulation. The debugger also provides single- 
stepping and program tracing. Since most debuggers 
interact with a teletypewriter, they provide minimum op- 
erator feedback. New debugger designs take advantage 
of the ultra high speed crt displays with increased in- 
formation feedback. 

High level language compilers translate a high level 
language program (in BASIC, FORTRAN, COBOL, PL/M, 
etc) into assembly language programs. Since each high 
level language statement represents a number of assembly 
language statements, the designer can shorten the amount 
of time spent generating a program. This time advantage 
normally contains an associated expense, since the com- 
piled code is not as efficient as assembly level code gen- 
erated by an experienced programmer; however, as 
memory becomes less and less expensive, compilers will 
become more cost-effective. 

Linkage editors link individual program modules, all 
of which are assembled or compiled separately. Thus, the 
designer can gradually build a library of commonly used 
subroutines and program segments and, as a last step, 
link these subroutines and program segments together 
to form an entire operating program. The linkage editor 
performs all the address calculations necessary to link 
the modules so that they can interface to each other 
and fit properly into memory. 

Consisting of an editor, assembler, monitor, debugger, 
compilers, and linkage editors, the operating system 
manipulates, stores, retrieves, loads, and executes system 
programs, and creates and deletes data files. Various 
utility functions, such as the ability to copy programs 


TABLE 1 
Operator Console Types and Major Function Times 


Operator 
Console 


Application 
Example 


Binary lamps and Front panel; Imsai 


switches and Altair computers; 
R DEC PDP-11 
Hexadecimal keyboard Intel SDK-85; 


and display ~ KIM-1 


Printer terminal.with Motorola EXORciser 
P/ROM debug monitor with Exbug, and TI 
Silent 700 terminal 


CRT terminal— Intel MDS with Intel 

120 to 960 char/s— CRT terminal; 

and debug monitor Tektronix 8002 with 
CRT terminal 

Memory refreshed Futuredata 

CRT display Microsystems 10, 15, 
20, and 30 


Debug Edit 
Function Time* Function 
(Overhead) Time? 

1¢ min Not practical 


180s Not practical 


120 s; includes 
time to write 
results; printing 
time is significant 


80s 240 s; must re-list 
to check edit 


480 s; must re-list 
to check edit 


40 s; minimum 
operator entry 


90 s; context 
editing 


1Standard debug example: set breakpoint, execute, examine register and 32 bytes of memory, make a 5-instruction patch, re-exe- 


cute, examine registers, and continue execution. 


2Standard edit example: change two lines, delete three lines, and insert five lines. Assume that all data are in memory. 


either in source or object form from one media to an- 
other, also are offered. 

The mass storage device attached to the system, such 
as paper tape, magnetic tape, and disc, principally dif- 
ferentiate the various levels of the overall operating sys- 
tems. 


Operator Console Levels 


Microcomputer development systems differ primarily in 
two hardware areas: the operator control console, and 
the type and speed of mass storage devices. Table 1 
shows five levels of operator control consoles. Early op- 
erator consoles contained binary lamps and _ switches. 
Even today, most minicomputers havea front panel con- 
taining a row of toggle switches and a row of lamps. 
Manual loading of an initial program is common prac- 
tice with these front panel switches. A bootstrap pro- 
gram inputs a more sophisticated loader through a paper 
tape reader and, finally, that loader program loads in 
the designer or system program, again from the tele- 
typewriter paper tape reader. Interaction with an op- 
erating program for debugging can also be done with 
panel lamps and switches. Obviously, this manual de- 
bugging method is tedious, evolving, as a result, many 
modifications to operator consoles. 

The first improvement added a printer terminal with 
debugger. Debuggers written around this terminal type 
provided a minimal response to each command since 
printer terminals were relatively slow (data rates of 
10 to 30 char/s). Each command deliberately limits in- 
formation; otherwise, the designer continually would be 
waiting for the terminal to finish printing the results 
of the last command. This in turn led to two further 
improvements: one in the direction of less cost (hexa- 
decimal keyboard and display) and the other in the 
direction of higher performance (CRT terminal). 

The hexadecimal keyboard and display are inexpen- 
sive methods of implementing an operator console. In- 
formation previously entered with switches and dis- 
played with binary lamps is now entered with a hexa- 
decimal keypad and shown on 7-segment light emitting 
diode displays. The keypad approach reduces operator 
entries from 8 or 16 switches to 2 or 4 keystrokes. This 
technique clearly minimizes operator errors but still 
does not provide much additional information. High 
speed CRT terminals, as implemented on most micro- 
computer development systems, merely act as high speed 
versions of a printer terminal. System software has not 
been updated to take full advantage of the crT terminal 
speed; only the process is accelerated by generating out- 
put data at a greater rate. 

The microcomputer development system designer uses 
the highest level of operator console, a memory refreshed 
crT display, to take into account the ultra high speed 
capability of the console at design time. Thus, a con- 
text based debugger and a context based editor can be 
provided. In this type of console, the designer sees a 
continually updated register display, large memory 
dumps, and whole segments of source code in context, 
greatly reducing the confusion as to exactly what is 
happening. This type of interactive software is designed 
around consoles that operate with data rates between 
10k and 50k char/s. The present state-of-the-art and 


direction of microcomputer development systems indi- 
cate that this level of operator console should become 
more prevalent in the future. 


Mass Storage Levels 


Small computers use four general levels of system mass 
storage. The first level is no mass storage facility. The 
designer keys in the program, usually in binary or hexa- 
decimal, and then executes immediately. The next level 
is paper tape based systems available on many small 
computers. The mass storage medium is punched paper 
tape, and the combined operator console and mass stor- 
age device is usually a teletypewriter. This level of stor- 
age system was dominant for many years, largely be- 
cause of excellent cost-performance characteristics. Only 
recently have crT displays and magnetic tape or disc 
systems been able to compete effectively with paper tape 
systems. The third level of mass storage is low speed 
magnetic tape (generally, cassette). Data are read and 
written into cassette tapes somewhere between 30 and 
400 char/s. This represents an improvement of 3 to 40 
times over the teletypewriter and makes low cost micro- 
computer development systems practical. This level of 
storage system is perhaps a good choice for relatively 
small programs (500 to 1000 lines or less), a limited 
budget, or an initial implementation of a development 
system. 

The fourth, generally accepted standard for mass stor- 
age on development systems is flexible disc, either a 
5.25” (13.34-em) or an 8” (20-cm) diameter version. 
Data transfer rates are greater than 1000 char/s. Ac- 
cess time and throughput for this mass storage device 
cease to be significant factors in development time. 
Comparisons of editing overhead times using teletype- 
writer, paper tape reader and punch, medium speed cas- 
sette tape, and fast flexible disc indicate that even for a 
100-line program, a teletypewriter is slow. Likewise, for 
a 1000-line program, the medium speed cassette based 
system is probably too slow. However, with a flexible 
disc based system, the designer edits and assembles 10k- 
line programs in a relatively short time. 


Development System Architectures 


Architectural considerations involved in comparing mi- 
crocomputer development systems relate to two basic 
implementations of in-circuit emulation—a master-slave 
approach, such as taken by Intel and Tektronix, and a 
single-processor approach, such as that of Motorola, 
Futuredata, and Zilog. Table 2 summarizes these archi- 
tectures and implications. 


Master-Slave System 


In a typical master-slave system (Fig 3), the master 
(host) microprocessor runs all system software func- 
tions, including editing, assembling, disc file manage- 
ment, and “downline loading” of object programs to,be 
tested in the prototype (target) microprocessor using 
in-circuit emulation. The target (slave) microprocessor 
is the designer’s microprocessor under investigation. The 
development system manuafcturer primarily accrues the 
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TABLE 2 


Development system Emulator Architectures and 
Associatéd Hardware/Software Devices 


Emulator Micro- Memory and : 
Manufacturer Architecture processors Peripherals Software CRT Display 
Futuredata Single processor 8080 Up to 64k Editor Memory 
(Microemulator) and common memory; 8085 Cassette Assembler refreshed 
allows full speed 8086 Floppy disc Debugger 
emulation and com- 6800 EPROM programmer Macro Assembler 
plete control of 6802 Logic analyzer Linker 
emulation modes; Z80 Printer BASIC Interpreter 
universal BASIC Compiler 
Intel Modified master- 8048 Up to 64k Editor RS-232-C 
(ICE) slave single memory; 8080 Paper tape Assembler Teletype- 
slows emulation 8085 Floppy disc Debugger writer mode* 
with wait states. 8086 EPROM programmer Macro Assembler 
Allows control of Logic analyzer Linker 
emulation modes; Printer PE/M Compiler 
nonuniversal FORTRAN Compiler 
Motorola Single processor 6800 Up to 64k Editor RS-232-C 
(USE) with common memory; 6802 Cassette Assembler Teletype- 
nonuniversal Floppy disc Debugger writer mode 
i; Printer Macro Assembler 
Linker 
BASIC Interpreter 
FORTRAN Compiler 
Tektronix Master-slave archi- 8080 16k Host, Editor RS-232-C 
(In-Prototype tecture with split 8085 Up to 64k Target Assembler Teletype- 
Emulator) memory; permits full 6800 Floppy disc Debugger writer mode 
speed emulation and Z80 EPROM programmer Macro Assembler 
control of emulation 9900 Logic analyzer Linker 
modes; universal Printer 
Zilog Single processor Z80 Up to 64k Editor RS-232-C 
(In-Circuit with common memory; Floppy disc Assembler Teletype- 
Emulator) allows only minimal Printer Debugger writer mode 


control of emulation 
modes; nonuniversal 


Macro Assembler 
Linker 
PL/Z Compiler 


*Teletypewriter mode: ORT display is treated as a byte-serial device with data rates of 120 to 960 char/s. 


advantages of such an approach. First, using a standard- 
ized host microprocessor minimizes software cost for im- 
plementing a new microprocessor. The second advan- 
tage is that less of the system resources need be re- 
served for the host system. 

A disadvantage of the master-slave system is that it 
splits memory into two separate spaces. The system 
programmer encounters more difficulty in dealing with 
a split memory and its discontinuous address space than 
with a single large memory. A single memory space 
more ‘effectively handles host functions that require large 
amounts of memory (editor work areas, and assembler 
and compiler symbol tables). Thus, 16k of host memory 
and 16k of prototype memory provide only a 150-line 
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edit buffer. The same 32k memory in a single large de- 
vice supports over 1500 lines of editor code (some of 
this advantage is due to packing the editor data). A 
second disadvantage is the higher cost that additional 
memory and microprocessors add to the system. 

A third and rather subtle disadvantage relates to mod- 
ification of the system programs. Most designers of com- 
puter systems realize that over a long period of time the 
supplied operating software will be modified. This modi- 
fication may add a new 1/0 peripheral device, for ex- 
ample, printer or paper tape reader or punch, 7-track or 
9-track tape drive, hard disc drive, or a number of de- 
vices not included in the original system. With the 
master-slave approach, the designer must modify pro- 
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Fig 3 Master-slave in-circuit emulator architecture. System and prototype functions are divided between 
master (host) and slave (target) microprocessors, respectively. System development functions, such as file 
management, text editing, host I/O, and debugging, are performed by master microprocessor. Prototype 
related functions, such as prototype program execution, prototype I/O, and in-prototype testing, are done 


by slave microprocessor 


grams written for an unfamiliar host microprocessor. 
Thus, an 8080 or 6800 designer might be confronted 
with the necessity of modifying code written for a 2650 
microprocessor. 

The Microemulator 11 systems permit both common 
and separated memories to be used, depending on de- 
signer requirements. A master-slave processor approach 
is used, but all memory is contiguous in the host sys- 
tem. The slave microprocessor is remote from the sys- 
tem (at the emulator plug), and none of its resources 
need to be reserved for the system. Software systems 
written in their native languages support the 8080, Z80, 
and 6800 families of microprocessors. 


Single-Processor System 


In a single-processor system (Fig 4), system software 
usually is written on the target microprocessor. Thus, 
a 6800 designer would modify 6800 code, an 8080 de- 
signer would modify 8080 code, and a Z80 designer 
would modify Z80 code. This type of development sys- 
tem can become a multipurpose device. After becoming 
familiar with the system hardware and software, many 
designers may use that same hardware in the develop- 
ment of test equipment that will follow the design 
through its production life. 


The clear cut advantage of a single-processor system 
is low cost, since much less hardware is included. A sec- 
ond advantage is that one large memory is furnished; 
thus, a 32k memory space provides for 26k of object code 
in the prototype system, and an assembler symbol table 
with many thousands of symbols. The Intel 1cE system, 
while a master-slave system, does provide for one large 
memory accessed by both microprocessors. To do this, 
the system delays the target microprocessor when it 
accesses development system memory. However, this 
compromises the ability to totally emulate prototype sys- 
tem operation. Another advantage of the single-pro- 
cessor system is the use of development system hard- 
ware and software as part of in-plant test equipment. 

A disadvantage of a single-processor system is that 
the manufacturer must entirely rewrite software pack- 
ages for each new microprocessor. Standardization trends 
in the industry make this less of a problem. A second 
disadvantage, depending on the application, is that emu- 
lation is not entirely separate. Thus, most single-pro- 
cessor systems reserve part of the memory space for 
system programs that must be resident during emulation. 
They generally have at least one privileged 1/o address 
to switch the system in and out of emulation mode. De- 
pending on the design of the single-processor system, 
it also may use some DMA capabilities and an interrupt 
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Fig 4 Single-processor in-circuit emulator architecture. Dedicated system development 
functions are programmed in related instructions for direct execution by target micro- 
processor. Differing target microprocessors require associated system software modifications 


structure. The designer can upgrade the emulation capa- 
bilities of the system as needed to support development. 


Summary 


Microcomputer development systems have common ¢a- 
pabilities of processor, memory, console, mass storage, 
in-circuit emulation, and system software. They differ 
in type of operator console, mass storage device, in- 
circuit emulation architecture, high level language sup- 
port, and whether or not they are universal (support 
a wide range of microprocessors from a variety of man- 
ufacturers). 

Development system support for the 8080 and 6800 
and their successor microprocessors is necessary. These 
two microprocessors are standards to some extent, be- 
cause of significant investment in 8080 and 6800 soft- 
ware. The 8080 standard includes as its successors the 
8085, the 8086, and the Z80. The 6800 standard includes 
as its successors the 6802, 6809, and 6502. In general, 
these successor microprocessors, with the exception of 
the 6502, have attempted to remain program compatible 
with earlier versions. Both microprocessor manufacturers 
and designers who invested substantial amounts of money 
in programs to support these microprocessors require 
this compatibility. 

With some 20 manufacturers, most of whom can intro- 
duce one or more microprocessors per year, a universal 
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development system becomes an essential tool for de- 
signers. Since the 8080 is 10 times more powerful than 
the 8008, the Z80 is 2 to 3 times more powerful than 
the 8080, and the Z8000 and 8086 are 5 to 10 times 
more powerful than the Z80, the pressure to adopt new 
microprocessors is intense. Thus, the designer must be 
able to switch the target microprocessor without start- 
ing from scratch. 
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